-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed change for Focus Navigation #381
Conversation
As discussed in WICG#375 This adds a clarification about focus navigation order for nodes distributed under a slot element. Also added handling tabindex="-1" case.
@hayatoito PTAL |
@@ -1139,6 +1141,27 @@ | |||
</li> | |||
</ol> | |||
|
|||
<p>Likewise, the <a>sequential focus navigation order</a> for <a>distributed nodes</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong... This should not be distributed nodes. This should be assigned nodes.
In addition to that, you should consider the followings:
- Do not forget to include descendants of assigned nodes into this focus navigation group.
- Consider the fallback contents of slots, in addition to assigned nodes.
- When you try to consider 1 and 2, do not forget the case where a slot is a descendant of another slot.
- The traversal order is not defined for sequential focus navigation order for distributed nodes. Define the traversal order of this focus navigation group.
- Exclude an assigned node (and more) from its root node's focus navigation group. One node should not join more than one focus navigation group.
- Mention how tabindex values are scoped at each focus navigation order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
Probably we want to start using 'control group' (defined in HTML spec) for the scope.
I am working on rewriting with it.
…nt is no longer dispatched
Addresses comments from hayato.
@hayatoito PTAL. I tried to get this upstreamable to HTML spec, section 6.4, So this is my attempt to include the #375 as exactly as possible by At this point it seems to me to patch the upstream spec requires lot more work. |
|
||
<p>If a <a>node</a> doesn’t <a data-lt="participates">participate</a> in the <a>document flat tree</a>, the <a>node</a> <strong>must</strong> be skipped from the <a>sequential focus navigation</a>.</p> | ||
|
||
<p>The <a>sequential focus navigation order</a> for a given <a>shadow tree</a> <var>A</var> <strong>must</strong> be inserted into the <a>sequential focus navigation order</a> for the <a>parent tree</a> <var>B</var> as follows:</p> | ||
<p>Each <a>shadow root</a> and <a>slot</a> element is a <a>control group owner</a> and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A control group is more upper layer concept, isn't it?
I mean:
- There is 1 : N relationship between [a control group] and [focus navigation order in each scope].
- There is 1 : 1 relationship between [a control group] and [global focus navigation order], which is the result of merging multiple [focus navigation order in each scope].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that frames own its own control group (e.g. <iframe>
) and its own sequence, but from user's standpoint, tab navigation sequence look global. Thus sequences for each group is merged.
I think you will not get a good definition by the current approach. I recommend you to have a more formal approach: e.g. algorithm:
algorithm:
Thus, we can define the disjoint sets clearly. Then, algorithm:
Thus, the oder is clearly defined. |
It looks iterative reviews won't work well if completely different structure is suggested. I've written the draft following your suggestion: For the 3rd algorithm (ordering) in the comment, In addition, do we want to describe how to compare 2 focusable areas with tabindex here That would add almost dead-copy of HTML 6.4.3 and |
@hayatoito comment on the doc linked above is welcome. |
Get ready for automatic publication - the HTML Imports spec
Somehow my brain hadn't made the switch so every time I worked on new text I kept reintroducing the old name. Oops.
Operating under the assumption that this is going to DOM, @annevk's specs don't use semicolons :-S
- Figure out where custom elements will go in HTML, and started writing as if they were there - Fleshes out and moved around examples and motivation to form an "introduction" section - Separates out and rearranges concepts a bit better (fixes WICG#437) - Moves the registry to the Window instead of the Document (fixes WICG#369) - Moves to `window.customElements`, an instance of `CustomElementsRegistry`, with one `define` method currently (fixes WICG#431)
@hayatoito Updated the draft. PTAL. |
- markup for <var> - period or colon at the end of bullet - more links to definition - remove title. - fix autolink
As discussed in WICG#375 This adds a clarification about focus navigation order for nodes distributed under a slot element. Also added handling tabindex="-1" case.
Addresses comments from hayato.
- markup for <var> - period or colon at the end of bullet - more links to definition - remove title. - fix autolink
@hayatoito this branch went into some weird state, so I created another PR #447. |
As discussed in
#375
This adds a clarification about focus navigation order for
nodes distributed under a slot element.
Also added handling tabindex="-1" case.